Succeeds #2411

To migrate to a standardized deployment approach, we'd like to move away from the legacy Azure DevOps release mechanisms. The best way I've seen to do that is to have a separate release pipeline which handles only release activities - the release pipeline must be quite restricted which causes issues even trying to run our security scanners and compliance tools such as SBOM, so trying to create a deployment off our existing pipeline served challenging.

This approach is based off of the vscode-csharp release pipeline. https://github.com/dotnet/vscode-csharp/blob/main/azure-pipelines/release.yml

An example run is here: https://dev.azure.com/dnceng/internal/_build/results?buildId=2858298&view=results

Other updates to make this work:

• Signing is not done on non-CI workflows by default, so we don't run into failures trying to pack when I run test pipeline runs in internal
• We print the pipeline workspace since it's the standard approach for staging deployment artifacts
• We pass the artifacts and package lock files to enable npm ci install of vsce. This is because we are blocked from installing updates in a ci machine so it would fail anytime a package sub dependency got an update (which happens nearly daily)
• updates get version logic and other logic to work in a new deployment scenario
• verifies PAT token
• removes custom SBOM logic as SBOM no longer fails as it used to

Thank you to @/joerobich who was very helpful in explaining the vscode-csharp-release structure.